home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1995…tember: Reference Library / Dev.CD Sep 95 RL / Dev.CD Sep 95 RL.toast / mac / Technical Documentation / develop / develop Issue 22 code / PCI Driver Sample / NCR_DriverProject / Framework NCR Sample Discussion < prev    next >
Encoding:
Text File  |  1995-03-11  |  9.1 KB  |  167 lines  |  [TEXT/ttxt]
  1. A Sample Device Driver
  2. for the New Device Driver Framework
  3.  
  4. Martin Minow
  5. December 23, 1994 (in progress)
  6. ===========================================================================
  7.  
  8. Introduction
  9. ~~~~~~~~~~
  10. This is a sample device driver that illustrates the new driver architecture that
  11. will become available with the Power Macintosh models that support PCI bus. The
  12. driver architecture will be used on future Macintosh operating system releases
  13. for Power PC and 68000 machines. The sample has the following characteristics:
  14. •    Small: most of the code is “administrative” — almost all code that is
  15. specific to the particular hardware is isolated into a few subroutines.
  16. •    Complete: the sample creates an asynchronous device driver that supports the
  17. NCR 8250 interface card that uses the NCR53C825 PCI bus interface.
  18. •    Vendor-neutral: the driver and its framework may be compiled under
  19. MetroWerks Code Warrior 1.2 or MPW 3.3. An AppleScript facilitates building
  20. multiple instances. [The AppleScript is not implemented yet]. The framework
  21. runs under MetroWerks and MPW. It has not been built or tested under Think C,
  22. although this should not present difficulties. The test program has only been
  23. compiled by MetroWerks.
  24.  
  25. Goals
  26. ~~~~~
  27. •    A working device driver sample for the New Device Manager architecture that
  28. •    illustrates asynchronous behavior and many of the new managers, and
  29. •    follows the device driver model that will be used in future Macintosh systems.
  30.  
  31. Non-Goals
  32. ~~~~~~~~
  33. •    Concurrence: (i.e. capable of processing more than one simultaneous
  34. operations). This would require a great deal of NCR53C825-specific programming.
  35. •    Full-scale: this driver illustrates the new driver architecture: it does
  36. not illustrate all capabilities of the new model.
  37. •    This is not a SCSI sample.The board used was chosen as as a readily-available
  38. hardware sample. This driver should not be used as a basis for a SCSI device
  39. driver (or SIM). In particular, Apple recommends that SCSI devices be supported
  40. by device drivers communicating through the SCSI Manager, and that SCSI bus
  41. adaptors be supported by SIMS controlled by = SCSI Manager 4.3.
  42.  
  43. The Sample Driver
  44. The driver allows an application program to issue SCSI commands directly to the NCR
  45. device. It does not support read/write or “drive” programming (i.e. it does not
  46. allow you to mount SCSI disks), but rather requires you to issue commands
  47. directly. In this regard, it functions somewhat like the SCSI Manager. In
  48. particular, it
  49. • Illustrates Primary Interrupt Service Routine processing.
  50. • Illustrates asynchronous I/O processing.
  51. •    Illustrates DMA, direct read/write of device registers, and Expansion Bus
  52. Manager programming.
  53. • Illustrates System Registry processing.
  54.  
  55. New Device Driver Architecture
  56. ~~~~~~~~~~~~~~~~~~~~~~~~~
  57. The Device Manager will be replaced beginning with the PCI machines. This new
  58. “native driver” architecture will be used for all new machines. While existing
  59. drivers will still work correctly, they cannot take advantage of Power Macintosh
  60. native code.
  61. Separation of function is central to the new architecture: drivers will not use
  62. Macintosh OS. services, and applications and non-driver code modules will not
  63. call the driver software library. This will mean significant changes for driver
  64. writers: parameters cannot be read from resource files, for example.
  65.  
  66. The Three Aspects of a Device Driver
  67. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  68. All device drivers contain three somewhat independent components:
  69.     1.    The low-level bus interface or “hardware abstraction layer” that reads
  70.         and modifies information in the external NuBus or PCI device.
  71.     2.    A mid-level component that has the device driver’s task-specific
  72.         intelligence. For example, this might contain disk driver buffering
  73.         algorithms. This part is unique to each driver.
  74.     3.    A high-level component that connects the Device Driver to the Macintosh
  75.         operating system.
  76. Currently, Macintosh device drivers mix all three “levels” together, making
  77. them hard to write and harder to maintain. The new driver architecture makes it
  78. easier to abstract these layers. In particular, the operating system now handles
  79. the messy details of the high-level component within itself, presenting the
  80. device driver writer with a small library of interface functions.
  81. Another problem with the current device driver architecture is the reliance on
  82. specific features and quirks of the 68000 hardware and programming architecture.
  83. For example, critical sections are implemented by blocking hardware interrupts
  84. and drivers complete I/O requests by storing specific values into hardware
  85. registers and setting the 68000 condition codes. Drivers also need access to
  86. 68000 registers and system low-memory global values. The new architecture was
  87. designed to facilitate high-level language implementation. It provides a
  88. programming interface that is specific to device drivers and isolates them from
  89. the Macintosh Toolbox (i.e. device drivers may no longer display dialogs.)
  90.  
  91. Converting Existing Device Drivers
  92. ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  93. For example, you may have developed a document scanner with an optical character
  94. recognition facility. The document scanner is controlled by a NuBus board that
  95. you designed, and you are building a PCI board to support the scanner on future
  96. Macintosh machines. In this model, the three aspects of the driver would be as
  97. follows:
  98.     1.    The low-level bus interface manipulates registers on the NuBus. For the
  99.         PCI system, this layer must be replaced with code that manipulates PCI
  100.         registers. Also, a moderate amount of code will have to be written to
  101.         support the PCI Device Registry.
  102.     2.    The mid-level component in this example would include scanner management
  103.         and, in particular, optical character recognition algorithms. These
  104.         algorithms comprise the intelligence that sets your product apart from
  105.         its competition.
  106.     3.    The high-level component in your driver that interacts with the Device
  107.         Manager can be thrown out and replaced with the considerably simpler
  108.         “New Driver Architecture.” This is executed directly on PCI Macintosh
  109.         systems. 
  110.  
  111. To convert your driver, you must do the following:
  112. •    Isolate the functional components of your driver. For example, you may have
  113.     an INIT, Notification Manager, Control Panel, parameter resources, and other
  114.     software modules that will need re-thinking. For example, parameter
  115.     resources will be replaced by data stored within the System Registry and
  116.     manipulated by Open Firmware components. Drivers that need extensive
  117.     parameterization should be loaded by INITs or applications that supply
  118.     necessary data through private PBControl calls.
  119. •    Rewrite your driver in very clean C code. Remove all 68000 assembly code and
  120.     driver-specific inline functions.
  121. •    Remove all references to the driver control block. Your driver’s private
  122.     storage will be stored in global and static variables — and the Code
  123.     Fragment Manager will handle initialization.
  124. •    Replace all memory management (NewPtrSys) by Pool Allocation calls.
  125. •    Add support for the Driver Gestalt PBStatus call.
  126. •    Replace accRun support by with non-interrupt code that is available to the
  127.     driver through calls provided by the Driver Service Library. In many cases,
  128.     accRun functions can be provided through a faceless background application
  129.     or INIT.
  130. •    Control Panels and applications cannot access the driver code or its
  131.     globals by using values in the DCE as this information is no longer visible
  132.     to the driver. If necessary, you should create a set of accessor PBControl
  133.     or PBStatus functions that manipulate your driver’s private values. The
  134.     Driver Gestalt handler and the private debugging control and status handlers
  135.     in the sample may be used as a model. While you could conceivably access
  136.     driver variables by using the Code Fragment Manager (the driver would
  137.     presumably export its variables), this should not be used for
  138.     production drivers. Instead, I would recommend exporting driver global
  139.     using a private PBStatus call as is done in the sample.
  140. •    In the new framework, drivers are limited to a small subset of the existing
  141.     operating system (the “System Programming Interface”). This will require
  142.     some rethinking of many drivers. For example, they cannot load information
  143.     from resources. The new architecture is not completely defined at this
  144.     writing, and additional capabilities will likely become available.
  145. •    If your driver may be used as a bootstrap device, plan for loading the
  146.     full driver into the card's EEPROM and write an Open Firmware boot driver.
  147.  
  148.  
  149. C or C++
  150. ~~~~~~~
  151. C, of course. The only advantage of C++ is the ability to write an base class
  152. for DoDriverIO. Since the framework is only a few pages of code, this is a
  153. small advantage indeed. Writing in C++ brings with it the disadvantage of a
  154. much more difficult debugging situation, especially if you take advantage of
  155. its operator override, method override, and object creation capabilities. And,
  156. if you don’t, why bother in the first place.
  157. Write your driver in very clean, very clear C. Measure its performance (use
  158. the new nanosecond library), and hand-tune only those parts of the code that
  159. need tuning.
  160.  
  161.  
  162. Further Reference:
  163. ~~~~~~~~~~~~~~~
  164. •    Inside Macintosh Devices.
  165. •    Designing PCI Cards and Drivers for Power Macintosh Computers
  166.  
  167.